Functionality Beyond BCBS 352 plus QIS Support

Vertex Interpolation

The term 'vertex' is used throughout BCBS 352 and it refers to a tenor or expiry/maturity point along which a risk factor sensitivity is mapped or projected. For example:

• GIRR Delta, where the vertices represent points along a risk-free yield curve.
• CSR Delta, where the vertices represent points along a credit spread curve.
• Commodity Delta, where the vertices represent time to maturity of a traded commodity.

It is worth noting there are no vertices for FX or Equity delta risk classes. For Vega, vertices represent option expiry dates. In all cases, the vertices are prescribed. For sensitivities that are not exactly mapped, linear interpolation to prescribed points has been implemented in the Reference Implementation based on a 30/360 day count convention. Other interpolation methods and day count conventions can be implemented as needed in the client project by implementing the respective configuration classes.

Parameterisation and context values

Parameters are soft-coded in the FRTB Accelerator which means that they can be overridden at query time without the need to rebuild or redeploy the application.

The parameters are held in a datastore and accessed by PostProcessors at query time. The parameters are stored with an additional two dimensions:

Parameters are looked up by AsOfDate and Parameter Set.

Multiple jurisdictions

The FRTB Accelerator allows configurable sets of parameters to be associated with a jurisdiction. It also allows the choice of jurisdiction to be made at query time via a filter. This means that:

• A trade or position can be associated with more than one jurisdiction
• The risk charge can be evaluated and compared against different jurisdiction parameter sets

There is no need to duplicate the complete configuration when creating a new parameter set. The FRTB Accelerator provides a parent/child relationship between parameter sets. Only values that need to be overridden compared to their parent parameter set need to be re-defined.

The name of a parameter set can correspond to a jurisdiction (e.g. EU, UK, JPN) or can be any other unique string.

The FRTB Accelerator is provided with a base set of parameters called BCBS. No data is provided by ActiveViam in the FRTB Accelerator for any other jurisdiction.

The data model in the FRTB Accelerator has a “parameter set” attribute as part of the key on the relevant data stores (and input files).

The Datastore Viewer is supplied in the Reference Implementation which allows the parameter sets to be browsed and modified. The Datastore Viewer does not apply any restrictions as to who can see the data and similarly there is no workflow associated with data changes. If a customer project requires workflow, authorisation or persistence on the parameter sets, custom development would be required during the project implementation to add those features.

Risk Charge Drill-In to Trade Sensitivities

The FRTB Accelerator contains functionality that allows a direct navigation path in ActiveUI from the risk charge to the risk position and then to the weighted sensitivities. This functionality is provided by a (right mouse click) context menu option in ActiveUI. On the IMA side the drill-in functionality is from IMCC by desk to book to asset class then to data set and liquidity horizon and finally to the PnL vector.

Multiple Business Days and Trends

There is support for multiple business days including trend analysis and support for slow moving data such as correlations and Risk Weightings.

The FRTB Data Model includes an AsOfDate key attribute. This allows the in-memory database to hold several days' data concurrently. The AsOfDate attribute is extended to other parts of the data model including the market data (FX rates) and parameters, allowing all the associated calculations to be date sensitive. This enables analytics to be performed over date ranges including the calculation of intraday changes to any measure. Trends can also be visualised by graphing the measures using AsOfDate as an axis on the charts.

Legal Entity, Desk and Book Hierarchies 

Desk Level for calculations (i.e. leaf level for dynamic aggregation PP) must be distinguished.  Variants of capital risk charge calculations must be allowed to address specific jurisdictional requirements, while providing an organisational hierarchy that could have desks and books at arbitrary depths and multiple legal entities.

Approach

The approach to creating and configuring Hierarchies, Cubes and Legal Entity filters is shown in the table below:

Capital Decomposition

Capital decomposition is all about allocating a top-level capital charge (which is the result of a non-linear calculation) to lower levels in the hierarchies in an additive way. 

There are several methodologies for achieving this. The FRTB Accelerator contains a number of implementations of linear allocation methodologies as described in this section.

 There are three main methods:

In the default accelerator implementation, we provide all of the above capital allocation methodologies as different measures. We expect clients to combine them together as they may feel appropriate. As an example, they may wish to make a measure which contains a mix of the analytical (where available) and numerical (for the remaining) Euler calculations.

Incremental Measures

Incremental measures show the impact at an all member level (such as across all books) of recalculating the measure without one of the members (books in this example). The FRTB Accelerator provides measures that compute the incremental impact for all the calculations in both SA & IMA up to the capital charge.

What-If Simulations

The FRTB Accelerator uses native ActivePivot what-if capabilities to deliver powerful simulation tools in four main areas: